The oneM2M standard under development defines a service layer called a “Common Services Entity (CSE),” which is shown in FIG. 1. The CSE is further described in oneM2M-TS-0001, oneM2M Functional Architecture (V0.4.2), which is incorporated by reference as if its contents are presented herein. A purpose of the service layer is to provide “horizontal” services that can be utilized by different “vertical” machine-to-machine (M2M) silo systems and applications, such as, for example, systems and applications related to e-Health, fleet management, and smart homes. Referring to FIG. 1, the CSE supports four reference points. The Mca reference point interfaces with the Application Entity (AE). The Mcc reference point interfaces with another CSE within the same service provider domain, and the Mcc′ reference point interfaces with another CSE in a different service provider domain. The Mcn is a standardized interface that allows the CSE to access functions in underlying network(s), while also keeping an underlying network mostly transparent to the CSE. The Mcn reference point interfaces with the underlying network service entity (NSE). An NSE provides underlying network services to the CSEs, such as device management, location services, and device triggering for example. The NSE's interfaces to the underlying network are not defined by oneM2M. Such interfaces are typically defined by the underlying network, but they may be proprietary interfaces that are defined by the network operator.
Referring also to FIG. 2, a given CSE may contain multiple logical functions called “Common Service Functions (CSFs).” Example CSFs include, presented without limitation, “Discovery” and “Data Management & Repository.” FIG. 2 illustrates CSFs under development at oneM2M. The illustrated Network Service Exposure, Service Execution and Triggering (NSSE) function interfaces with the underlying network(s). Current functions supported by NSSE are device triggering and location management. The Application and Service Layer Management (ASM) CSF shown in FIG. 2 provides software configuration and management for the software module of a CSE or an application entity (AE), for example, to install, activate, and de-activate software at the service layer.
Prior to oneM2M, ETSI M2M published its own service layer oriented M2M standard, which is defined in ETSI TS 102.690, Machine-to-Machine (M2M) Functional architecture (V2.1.1), which is incorporated by reference as if its contents are set forth herein. The architecture of oneM2M is similar to ETSI M2M. ETSI M2M defined the Service Capability Layer entity that consists of various service modules called Service Capabilities. The services can be exposed to the underlying network by the Network Exposure Service Capability.
Referring now to FIG. 3, 3GPP defined the MTC architecture in 3GPP TS 23.682, Architecture enhancements to facilitate communications with packet data networks and applications, Release 11, V12.0.0, which is incorporated by reference as if its contents are set forth herein. The MTC Application in the external network is typically hosted by an Application Server (AS) and may make use of an SCS for additional value added services. The 3GPP system provides transport, subscriber management, and other communication services (e.g., control plane device triggering) including various architectural enhancements for MTC devices. 3GPP defined three communication models for MTC devices: direct model, indirect model, and hybrid model. In the direct model, the AS connects directly to the operator network in order to perform direct user plane communications with the user equipment (UE) without the use of any external SCS. The Application in the external network may make use of services offered by the 3GPP system. In the indirect model, the AS connects indirectly to the operator network through the services of an SCS in order to utilize additional value added services for MTC (e.g., control plane device triggering). In the hybrid model, the AS uses the direct model and indirect model simultaneously in order to connect directly to the operator's network to perform direct user plane communications with the UE, while also using an SCS. From the 3GPP network perspective, the direct user plane communication from the AS and any value added control plane related communications from the SCS are independent and have no correlation to each other even though they may be servicing the same MTC Application hosted by the AS.
FIG. 3 is reproduced from the oneM2M architecture specification referenced above. FIG. 3 depicts how the oneM2M reference points can apply to the 3GPP MTC architecture. An Application Service Node is a Node that contains one Common Services Entity (CSE) and contains at least one Application Entity (AE). For example, an Application Service Node can be an M2M device. An Infrastructure Node (IN) is a Node that contains one Common Services Entity and contains zero or more Application Entities. For example, an IN can be a network server. The Mcc referent point shown in FIG. 3 is between the IN-CSE and the ASN-CSE on top of the 3GPP network.
3GPP defines its Operations, Administration, Maintenance (OAM) architecture for network management in 3GPP TS 32.101 Telecommunication Management: Principles and high level requirements, which is incorporated by reference as if its contents are set forth herein. As described, a Network Manager (NM) provides a package of functions with the responsibility for the management of Network Elements, such as devices and equipment. The management functions include account management, fault management, quality of service (QoS), performance management, etc. The management procedures are supported by open standards, such as Simple Network Management Protocol (SNMP) for example.
The Simple Network Management Protocol (SNMP), as defined in RFC 3411, is considered to be an application layer protocol in the OSI model. SNMP is commonly used to manage devices in networks. A computer network system that uses SNMP for network management may consist of the following components: the SNMP manager, the SNMP agent, and the SNMP Management Information Base (MIB). The SNMP manager may be software that runs on the machine of a network administrator or any human manager managing the computer network. The SNMP agent may refer to software that runs on the network node that is to be monitored. This node may be a printer, router, etc. The SNMP MIB, which is defined in RFC 3418, is a component that ensures that the data exchange between the manager and the agent remains structured. The MIB is constructed in a tree structure, and the basic component of the structure is an object. For example, the system up time can be represented as “iso.org.dod.internet.mgmt.mib-2.system.sysUpTime”.
SNMP communication between manager and agent takes place in form of messages. Basic example messages used for communication include: SNMP GET, SNMP GET-NEXT, SNMP GET-RESPONSE, SNMP SET, and SNMP TRAP. The messages GET and GET-NEXT are used to fetch the value of a particular MIB object. The message GET-RESPONSE is used mostly by the agent to send the response to a GET or GET-NEXT message. The message SET is used by the manager to set the new value of a particular MIB object at the agent. The message TRAP is used by the agent to send information about some alarming values for some object to the manager.
Through SNMP, one can retrieve information about network devices such as routers, printers, hubs, or general computers. Retrieved information may include system up time, CPU usage level, network settings, or the like. The devices can also be configured by SNMP.
SNMP usually works with policies to provide an overall management framework. For example, a network administrator can configure an event policy that raises traps for events based on system log messages. Threshold poll policies can set up different thresholds to monitor system and network information, such as memory usage for example.
A W3C Network Information API provides an interface for web applications to access the underlying connection information of a device. The W3C specification currently requests the user agent to expose two properties: bandwidth and metered. It seems that the interface is directly between applications and the underlying network.
Potential network connectivity issues, such as overloading, congestion, and weak signal strength, can cause non-optimized end-to-end M2M connections, such as, but not limited to, connection interruptions for example. In some cases, applications running over the networks are not aware of the network situation, or applications may be only aware of the condition of the local network where they reside. Network issues can cause long delays and even drop of connections at the application level. Such issues can apply to non-M2M systems as well as M2M systems. The issues may be more obvious in M2M networks than non-M2M systems due to various factors such as, for example, a large number of applications, the constrained (e.g., low-power, lossy) devices, and limits in local networks. For example, constrained applications might not be able to support build-in intelligence to handle connection issues. As another example, constrained application may keep their transaction regardless of a change of network connection. As yet another example, constrained applications typically cannot adapt their transactions with the consideration of other applications. Thus, as described above, current approaches to network and application management, for instance in networks with resource constrained (e.g., M2M) devices, lack capabilities and efficiencies.